Hi everybody.
I use dokuwiki for about 7 years now, in multiple projects and pages, and often I'm irritated by page loads.
I have somehow slow server, and slow network connection, and was wondering if loading of dokuwiki pages can be improved.
I performed some analysis using commonly available tools, and many design decisions are very good, but there is still few areas where we can improve page load substantially.
Some optimizations are about default template, but some of them are independent of it, and everyone will take benefit.
So I performed some tests and found few places where great improvements can be done:
1. Serve remote images directly without redirect. This can be accomplished by caching remote images directly in dokuwiki cache, this also helps if remote image is removed without our knowledge. Other solution is to fetch remote resource by dokuwiki code itself on the fly, than to use web browser for this. It can increase load on dokuwiki server, but can be beneficial especially if resource is on the same domain as dokuwiki host. (load and bandwidth will be the same, but latency will improve).
Example:
http://smp.if.uj.edu.pl/~www-wiki/wiki/lib/exe/fetch.php?w=60&media=http%3A%2F%2Fsmp.if.uj.edu.pl%2F%7Ebaryluk%2Fjabber.png
AFAIK, there was option for caching locally on server remote images, but this doesn't work anymore for some reason.
2. Merge buttons on bottom of the dokuwiki template, and use CSS sprites. Currently there is from 10 to 20 small images on dokuwiki, and it would be better to merge this 20 images each about 1kB into single image of about 20kB and perform single request.
Example:
http://www.dokuwiki.org/lib/tpl/default/images/button-xhtml.png
http://www.dokuwiki.org/lib/tpl/default/images/button-css.png
http://www.dokuwiki.org/lib/tpl/default/images/button-php.gif
http://www.dokuwiki.org/lib/tpl/default/images/button-donate.gif
http://www.dokuwiki.org/lib/images/license/button/cc-by-sa.png (this last harder, because license can be changed, but still this sprite generation can be done once, and cached on server).
This can be easily turned into css sprites. And will make difference.
There is also multiple icons on page, for example, near each link (internal, external, wikipedia, dokuwiki, mailto, file), but do not know if this can be turned into sprites easily (IMHO it should improve load, because there is small number of them, and if some of them are not used, it will not provide big overhead; however it can be technically hard to do, because of how currently this links are styled).
Example:
http://www.dokuwiki.org/lib/images/interwiki/wp.gif
http://www.dokuwiki.org/lib/images/interwiki/doku.gif
http://www.dokuwiki.org/lib/tpl/default/images/mail_icon.gif
There is also smiles images. But again, it can be waste to use sprites with all smiles if only single is used.
Example:
http://www.dokuwiki.org/lib/images/smileys/icon_wink.gif
http://www.dokuwiki.org/lib/images/smileys/icon_exclaim.gif
3. Make it easy to move static content (i.e. static images) to different domain (so no cookies are sent).
4. Merge all 3 css into single one with @media queries.
Some analysis here
http://tools.pingdom.com/fpt/#!/AaJVHDotN/http://dokuwiki.org
and (some older version of dokuwiki)
http://tools.pingdom.com/fpt/#!/bw9n2mn6H/smp.if.uj.edu.pl
Caching of resources, even dynamically generated is done relatively good (explicit 1h cache expiration + etag based on md5 hash of content, which can be quickly rechecked on server). Static content is also nicely cached, by example on apache, by doing Etags based caching (which uses inode number, file size and modification time, to calculate etag). However, first page load, cannot use caching, and it is good to perform as small number of requests as possible. All 4 solutions pointed above by me, can reduce page load time significantly.
What do you think? I think dokuwiki is mature enough to think deeper about some minor improvements now.